“微盟系统遭恶性删库事件”深度报告：今天就用3W方法还原其前因后果，并反思有哪些教训

【ZOOM CEO Eric Yuan当年经常对我们说，敲他Office的门之前，要把三个问题想清楚：What’s problem？ What’s root cause？What’s solution？这就是3W方法。今天我就用3W方法来分析 “微盟系统遭恶性删库事件”】

1. 问题是什么？

先上视频，问题（problem）就清楚了。如果心疼自己的流量，就跳过视频，直接看后面的“事件简要回顾”文字。

本次系统故障历经36小时，时间不算短，下面简要回顾一下：

• 今年2月23日，18:56分，微盟研发中心运维部核心运维人员通过VPN登入服务器，并对线上生产环境进行了恶意破坏，包括数据库备份服务器；
• 2月23日 19 时，微盟内部系统监控报警，出现大面积服务集群无法响应，生成环境即数据遭受严重破坏，微盟公司立即启动应急响应机制；
• 2月24日，微盟在成功定位到嫌疑人登录账号及IP地址后，向宝山公安局报案。目前犯罪嫌疑人已被宝山区公安局刑事拘留，承认了犯罪事实。
• 2月25日7 时，生产环境和数据修复在有序进行（即得到部分恢复），预计25日晚24点生产环境修复将完成，到时新用户将得到正常服务，而老用户数据修复需要更多时间，直到2月28日晚上才有可能恢复。

咱们可以想象一下恢复的场景——先要从备份系统中找到最近的备份数据，然后去恢复一项一项数据，有时恢复进行了大半才发现一开始备份数据存在问题，无法正常使用… … 数据恢复的速度不会因为任何人的焦急加快分毫，36个小时不够，是整整五天——120个小时，百万用户在等着，微盟集团运维负责人现在是何等的压力与煎熬！虽然我们不身在其中，但能感同身受。这次事件是“双输”的典型案例：

1. 从受害方微盟集团看，经济和公信力受到双重打击，特别是极大影响微盟的社会形象和商业生态，这种损失是不可估算的。截至2020年2月25日10点整，微盟集团报5.620港元，跌幅5.23%,市值约蒸发12.53亿港元，同时带给微盟客户的损失不可估量，特别是对微盟的老用户，由于系统故障5天无法使用服务，某些客户受疫情影响，其线下业务已经遭到重创，那现在线上业务又受到打击，真可谓屋漏又逢连阴雨。
2. 对犯罪嫌疑人，根据《刑法》第二百八十六条等相关规定，如果达到“后果特别严重”这一标准，将被处五年以上的有期徒刑。之前，杭州某科技公司的技术总监，也是因不满被老板开除、心生报复，删除了数据库上的一些关键索引和部分表格（破坏比此案小多了），其结果因破坏计算机信息系统罪被判处有期徒刑二年六个月。

2. 根因是什么？

那问题发生的根本原因（root cause）是什么？

可以从人、技术、流程和管理等角度来分析问题的根本原因。

首先是人的问题，如上述微盟公告所说，犯罪嫌疑人因精神、生活等问题。虽然我们不知道这位运维人员经历了怎样的精神压力和生活困难，甚至网传该员工向网贷借款后无力偿还，导致精神失常。

人的管理问题是很复杂，一些关键岗位的人（具有某种特地权限的人）是不是需要精心挑选？运维人员的心理素质、日常行为规范是不是应该有更高的要求，要高于一般开发或测试的工程师。在人员招聘或选用期间，我们就需要格外小心，多一些参与面试、也增加一些考验。有人说，知面不知心，难啊！的确很难，我有时也想，那些大领导选择贴身保镖是如何遴选的？

人的问题，不仅仅是挑选的问题，而且还包括平时教育和培养的问题。对运维人员、安全人员要进行必要的法律教育。要知道，许多事情是不能干的，如果压力山大或有报复心理，不冷静去做某些事情，会后悔一辈子。许多公司还会雇佣心理医生，疏导员工心理问题，开设心理课程等。

如果没有特别好的遴选办法，就需要增加系统维护某些操作的难度，例如金库的门打开需要两把钥匙，银行柜台操作人员进行更危险的操作时需要更高一层主管的授权。例如远程IP访问的权限很低，但在这疫情期间，的确会比较麻烦。

堡垒最容易被内部攻破，运维人员拥有特权的合法用户账号，那些常见的、防范黑客的安全措施，对维护人员一点作用都没有。必须有专门针对维护人员的安全防范，如限制使用rm -rf /*这样的命令。

其次是技术上的问题。删库这样的事，发生过多次，不管是有意还是无意的。之前，本公众号也报道过类似的事件：删除对象搞错，造成Gitlab丢失了6个小时的数据。造成这样的事件技术上的原因主要有：

1. 缺乏对数据保护更全面的规划，没有一套完整的数据保障体系；
2. 有防黑客的安全措施，没有防内鬼的安全措施。这个问题比较容易发生，因为运维的管理制度本身就是由运维人员来制定，如果高层CIO/运维总监不亲自抓这样的事或不专业，这样的漏洞就大概率会存在。
3. 权限设置是否合理。
   
4. 备份/恢复技术还比较落后；
5. 没有异地备份（灾备）数据中心或多节点备份机制，也没有更可靠的故障转移机制；
6. 平时没有做过演练。这次恢复的时间很长，部分恢复是36个小时，而整个恢复将超过5天。

遗憾的是，我们不是当事人，无法从问题出发，找来微盟集团运维内部的流程、规章制度分析，也无法找更多相关人来一起分析。咱们更不是微盟集团的CEO/CIO，把集团运维负责人找来问话，问他为什么会出现这种情况？根据他的回答，一步一步问下去。根据5 WHY方法，刨根问底就能找到问题的根本原因。

3. 解决方案是什么？

问题产生的根本原因找到了，其解决方案（solution）也就不难了，我们就能找到对症下药的解决办法。

首先要解决人的问题，多给员工一些必要的关怀和培训。正如上面所说的，对自己的招聘环节需要重新审视一遍，看看有没有改善的地方。平时员工的培训，特别是核心员工的培训，不能局限于专业技术（如Linux、shell脚本、网络协议、DevOps、AIOps等）的培训，而且需要进行职业道德、法律、心理等多方面的培训。

其次，要审视运维相关流程、规章制度和环境安全设置等，其中有没有漏洞，例如root权限的密码是不是受到严格的保护、通过远程IP地址访问的用户干不了任何危险的操作。有些专业公司还开发了“特权会话管理器”，杜绝危险操作、监控危险操作行为、定期更改root密码（连维护管理员都不知道）。

最后，在技术上增强数据安全保障措施，健全数据保障体系：

• 是否考虑全面部署自动化运维工具，极大地降低手工误操作带来的风险。
• 运维人员分工更细一些，设置更细、更安全的权限管理机制——不同级别的执行权限及对应的审批权限。
• 业务运维、网络运维、DBA 等都不能执行系统层的 rm 指令，系统运维也不能执行数据库的指令
  
• 在系统架构和系统备份技术上是不是需要升级换代？例如备份系统每次备份在完成之后，会自动完成数据有效性验证。
• 是不是要做常规的防灾演练，虽然很难。不在生产环境做，可以在测试环境、准生产环境进行演练，模拟各种可能的情况，类似混沌工程、可靠性故障注入测试等。
•  要不要加大投入、增加异地备份机制或者引入CDM（Copy Data Management）这种备份新技术？
• ......

其中CDM是以“原格式”（Disk Native Format）和“活跃黄金副本”（Live Golden Image）为特征的数据备份方式，囊括了备份、复制、存储、快照、虚拟化、及云管等多项特性。

CDM的“原格式”使得备份数据直接可用，在逻辑错误或人为错误发生的时刻，可以不经过格式转换和IO拷贝，直接挂载到应急主机上，快速应急恢复拉起，业务RTO时间可由原来的Day、hour级别缩短到分钟级。

此次事件对IT圈、对运维同行、对CIO/CEO等，都将是一次深深的警示教育，会让大家很好地反思，吸取教训，让这样的悲剧不会再发生。只是人类的忘性很大，倒是更相信悲剧还会发生，特别是那些中小型公司，可能更无法避免这样问题的发生。

参考：

• 只要坚信自己，任何目标都是能实现的

• 不得不谈谈农历新年首次质量大事故：GitLab丢失数据

• QECon演讲话题征集令到了，欢迎来接